Bye PE-Crypt v1.02
by Iczelion & Plushmm [Phrozen Crew]


Introduction
------------
It has long been rumoured that PE-Crypt is by far the most secure of 
all PE-encrytors.  The current version of PE-Crypt is v1.02 and has 
been authored by Random, Killa and Acp.

This c0ding project by Iczelion & Plushmm shows that with sound
reverse-engineering practices and a little patience ;)  even the
"uncrackable" is fallable.

More importantly, we wish to show the people in "the scene" that using
a third-party "protector" is no substitute for *your own* protection
scheme.  Hopefully lame KG stealers and crackme authors that use 
PE-Crypt (or a similar product) to hide their dirty work will wake up 
and smell the coffee.


Usage
-----
Run XPecrypt and select your PE-Crypted [v1.02] file.  A dialogbox will
then appear, asking you to name the decrypted file.  Simply enter the
name you wish to give to your fully de-crypted file.
The PE-Crypted file has been fully decrypted and unpacked for your
inspection ;)

NOTE: XPecrypt will overwrite the output file if it already exists!

You can also use XPecrypt via the command line.
The syntax is:  XPecrypt [-i] <pecrypted filename>

-i option is optional. It's for the extreme cases when XPecrypt cannot 
reconstruct the names of DLLs in the import section correctly. This 
option tells XPecrypt to show ALL DLL names it is processing and asks 
the user for confirmation. This way, you can control the DLL name 
decryption process yourself.

For example,
XPecrypt -i   
Tell XPecrypt to be in DLL name confirmation mode.

XPecrypt -i crackme.exe
Tell XPecrypt to be in DLL name confirmation mode and also decrypt
crackme.exe


Technical Notes
---------------
This decrypter/unpacker attempts to performs a *total reversal* of the 
PE-Cryption process.  No dumping is involved.  
In fact, Xpecrypt performs so well that when we encrypted netscape.exe
with pecrypt, the encrypted file could not run. But when we used 
Xpecrypt on it, the restored file worked fine :)

XPecrypt works on files encrypted with PE-Crypt v1.02 only.

Several issues should be mentioned here about how PE-crypt performs 
decryption because they are directly related to the quality of the 
output files.

PE-crypt destroys the high 4 bits of every relocation entry if it is 
instructed to use 12-bit encryption or relocation packing. So in this 
case, XPecrypt cannot guarantee that it will be able to obtain the 
original relocation section back. However, this issue has little 
importance for EXEcutable files because they are always loaded at the 
preferred load addresses so relocation fixups are not needed. 
However, DLLs are a different stories entirely.  DLLs will quite 
possibly be forced to load at different load addresses because the 
preferred addresses may be already taken up by some modules.
In that case, relocation fixups are necessary.
This is one of the reasons why PE-Crypt doesn't work very well with 
DLLs.

PE-Crypt merges the section that contains import table with the 
previous section if import hiding option is turned on. In this case, 
the total number of sections will be decreased by one.  However, the 
decrypted files will still work ok even if the file sizes differ from 
the original files.

PE-Crypt changes the characteristics/attributes of all sections to
readable and writable for its own conveniece in decryption/decompression.
XPecrypt has no way to know the original values of those sections.
However, the decrypted files work ok with those attributes.

PE-Crypt encrypts the names of the DLLs in the import section. Most of 
the time, the decrypter will be able to decrypt them. However, there 
may be some instances when it's not sure whether the names are correct.
The current method used by XPecrypt is to use 0 as the end of the DLL 
name marker. However, the encrypted bytes may possibly be 0s. In those 
instances, it will display a messagebox showing the currently decrypted
name of the DLL and ask you if this name is correct. If you reply yes, 
it will go on to the next DLL. If the answer is no, it will interpret
the current 0 as an encrypted byte and will continue with the 
decryption of the current DLL name.
Don't be overly concerned about this issue. If you answer incorrectly,
you can always run XPecrypt again and again, or you can use DLL name 
confirmation mode by specifying -i in the commandline.
In this mode, XPecrypt will show the name of every dll it is decrypting
and ask you if the current DLL name is correct.

We have encountered situations when all the sections in a PE-Crypted 
file has been changed to .ficken
XPecrypt has no way to know the original names so it doesn't do
anything with them.  But don't be worried. The files run fine whatever
the section names are.